perm filename SPIDE2.LSP[F81,JMC] blob sn#632505 filedate 1982-01-04 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	 spide2.lsp[f81,jmc]	spider player and referee
C00008 ENDMK
CāŠ—;
;;; spide2.lsp[f81,jmc]	spider player and referee
;;; using move.lsp[f81,jmc]
;;; The object is to get a transparent LISP program that closely models
;;; the physical actions involved in playing the game.

;;; shuffles a list in random order
(defun shuffle (u)
       (if (or (null u) (null (cdr u)))
	   u
	   (shuffle1 u nil nil)))
(defun shuffle1 (u w1 w2)
       (if (null u)
	   (append (shuffle w1) (shuffle w2))
	   (= 0 (random 2))
	   (shuffle1 (cdr u) (cons (car u) w1) w2)
	   (shuffle1 (cdr u) w1 (cons (car u) w2))
	   ))


(setq piles '(p1 p2 p3 p4 p5 p6 p7 p8 p9 p10))

(setq suits '(C D H S))

(setq denoms '(1 2 3 4 5 6 7 8 9 10 11 12 13))

(defun cartesian (u v)
       (mapappend
	(function (lambda (x) (mapcar
			       (function (lambda (y) (list x y)))
			       v)))
	u))

(defun mapappend (f u) (if (null u) nil (append (funcall f (car u))
						(mapappend f (cdr u)))))


(setq ideck (append (cartesian suits denoms) (cartesian suits denoms)))

;;; Some notes.
;;; Processes include:
;;; 1. Creating a deck.  This is a higher level process than those involved in
;;; playing.  We need not provide it initially but can settle for a few fixed
;;; decks.  It involves specifying parameters such as suits and denominations,
;;; deciding on Cartesian products or subsets thereof as decks, and introducing
;;; relations such as ordering among cards.  We need to distinguish betweeen
;;; kinds of cards and cards themselves, since the deck may have two jacks
;;; of clubs.  Maybe gensym is used.
;;; 
;;; 2. Shuffling a deck.  This action assumes that the cards have an initial
;;; order.  We can suppose that the shuffle completely randomizes the deck
;;; or rather we needn't provide a language to distinguish different
;;; shuffling rules.
;;; 
;;; 3. The initial deal. It would be elegant and perhaps also convenient to
;;; describe the operation of dealing in terms of the operations for moving
;;; sequences of cards and exposing cards.
;;; 
;;; 4. Moving sequences of cards.  We distinguish physical moving from legal
;;; moving.  Physically anything may be moved anywhere and the physical
;;; move routines provide for this.  The same repertoire of physical moves
;;; can support different solitaire games.  In fact we could imgine that
;;; the player (human or program) specifies physical moves, and the particular
;;; solitaire rules are embodied in a referee observer who complains if the
;;; moves are illegal.  The following diagram of interacting automata may
;;; be useful. [The diagram includes the strategist, the physical world,
;;; an observability filter and a referee].
;;; 
;;; 5. A theory of piles.  Objects can be taken from the top of a pile and
;;; put on other piles.
;;; 
;;; 6. The solitaire world.  There are piles of cars. Some are down and some
;;; are up.  The rules determine the possibility of moving sequences from one
;;; stack to another.  These rules cannot depend on the values of the
;;; down cards.  Cards may be discarded onto a junk pile.
;;; 
;;; Perhaps a general solitarie simulator can be constructed out of primitives.
;;; We cansuppose that the integers can be taken as the locations of piles.